greenplum的motion机制

查询计划会根据sql语句的预估开销来决策选择哪种motion，一般情况下，假设我有语句GP相比其他数据库有的操作类型，有一个额外操作类型叫做motion,一个motion操作会涉及segment进行查询时的数据移动。并非所有的操作都会触发moiton操作。例如精确查询，不会涉及到segment之间的数据交互。当sql语句涉及到join、aggregation、sort（或其他对于行的操作)，就会有移动数据的需求，GP生成查询计划的时候会有motion node出现。

GP有如下几种motion方式：

  • Broadcast Motion：广播方式，每个节点向其他节点广播需要发送的数据。
  • redistribute motion：重分布移动数据，当sql语句做join的时候，join的列值hash不同，将筛选后的数据在其他segment重新发布.
  • explicit redistribute motion：
  • gather motion : segment数据汇聚到master。

    使用哪种motion

    关于gather motion

    查询计划会根据sql语句的预估开销来决策选择哪种motion，以tpc的语句为例，查看其执行计划
    1
    2
    3
    4
    5
    explain select  count(*) from store_sales,household_demographics ,time_dim, store
     where ss_sold_time_sk = time_dim.t_time_sk and ss_hdemo_sk = household_demographics.hd_demo_sk 
     and ss_store_sk = s_store_sk and time_dim.t_hour = 8 and time_dim.t_minute >= 30 
     and household_demographics.hd_dep_count = 5 and store.s_store_name = 'ese'  
     order by count(*)  limit 100;

返回结果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
                                                                QUERY PLAN                                                                 
-------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=48894949.71..48894949.71 rows=1 width=8)
   ->  Sort  (cost=48894949.71..48894949.71 rows=1 width=8)
         Sort Key (Limit): count
         ->  Aggregate  (cost=48894949.69..48894949.70 rows=1 width=8)
               ->  Gather Motion 64:1  (slice4; segments: 64)  (cost=48894949.01..48894949.67 rows=1 width=8)
                     ->  Aggregate  (cost=48894949.01..48894949.02 rows=1 width=8)
                           ->  Hash Join  (cost=6682.50..48894930.40 rows=117 width=0)
                                 Hash Cond: store_sales.ss_hdemo_sk = household_demographics.hd_demo_sk
                                 ->  Hash Join  (cost=5484.50..48892272.13 rows=1220 width=4)
                                       Hash Cond: store_sales.ss_sold_time_sk = time_dim.t_time_sk
                                       ->  Hash Join  (cost=77.98..48866731.58 rows=42932 width=8)
                                             Hash Cond: store_sales.ss_store_sk = store.s_store_sk
                                             ->  Append-only Columnar Scan on store_sales  (cost=0.00..41199584.68 rows=44999812 width=12)
                                             ->  Hash  (cost=77.18..77.18 rows=2 width=4)
                                                   ->  Broadcast Motion 64:64  (slice1; segments: 64)  (cost=0.00..77.18 rows=2 width=4)
                                                         ->  Seq Scan on store  (cost=0.00..76.53 rows=1 width=4)
                                                               Filter: s_store_name::text = 'ese'::text
                                       ->  Hash  (cost=3350.51..3350.51 rows=2571 width=4)
                                             ->  Broadcast Motion 64:64  (slice2; segments: 64)  (cost=0.00..3350.51 rows=2571 width=4)
                                                   ->  Seq Scan on time_dim  (cost=0.00..1680.00 rows=41 width=4)
                                                         Filter: t_hour = 8 AND t_minute >= 30
                                 ->  Hash  (cost=622.00..622.00 rows=721 width=4)
                                       ->  Broadcast Motion 64:64  (slice3; segments: 64)  (cost=0.00..622.00 rows=721 width=4)
                                             ->  Seq Scan on household_demographics  (cost=0.00..154.00 rows=12 width=4)
                                                   Filter: hd_dep_count = 5

可以看到执行计划中有3个brodacst motion，每个segment在这步slice(查询计划中能独立执行的单元)中都会做brodcast，以最后一步的-> Broadcast Motion 64:64 (slice3; segments: 64) (cost=0.00..622.00 rows=721 width=4) -> Seq Scan on household_demographics (cost=0.00..154.00 rows=12 width=4) Filter: hd_dep_count = 5为例，每个segment都会将household_demographics表的结果集hd_dep_count广播给其他所有的segment。因此，结果集会影响brocastmotion的性能。
如果类似的操作需要大量的结果集，那gp的查询计划会评估需要gather motion动作开销太大，会改变执行计划将将一部分工作在segment内部完成掉。

关于redistribute motion

以sql语句SELECT customer, amount FROM sales JOIN customer USING (cust_id) WHERE dateCol = '04-30-2008';为例，customer 表的分布键为cust_id，而sales的分部件为sale_id,为了较高效的完成这个join，我们指定sales表也必需使用cust_id重分布，此时执行查询计划会有三个slice。可以看到查询计划如下:

1
2
3
4
5
6
7
8
Gather Motion 64:1  (slice2; segments: 64)  (cost=385.75..2857.25 rows=157480 width=460)
   ->  Hash Join  (cost=385.75..2857.25 rows=2461 width=460)
         Hash Cond: sales.cust_id = customers.cust_id
         ->  Redistribute Motion 64:64  (slice1; segments: 64)  (cost=0.00..472.00 rows=194 width=234)
               Hash Key: sales.cust_id
               ->  Seq Scan on sales  (cost=0.00..224.00 rows=194 width=234)
         ->  Hash  (cost=227.00..227.00 rows=199 width=226)
               ->  Seq Scan on customers  (cost=0.00..227.00 rows=199 width=226)

具体解读：
slice1：扫描cutomsers表，同时扫描sales表，并将sales表按照cust_id做重分布，根据hash结果将数据移动到对应的segment上。
slice2:每个segment把重分布过后的结果集拿来做hash join，并将join的结果集传输给master。

关于explicit redistribute motion

在官网上看到有redistibute motion类型，但没看到资料，也没成功触发过

关于gather motion

一个query会生成query plan，由master将query plan拷贝给各个segment运行，各个segment在运行完query plan之后会把各个数据返回给master，数据返回这个动作会有gather motion。
大部分操作都有gather motion，但并非所有。比如create table,insert 之类的没有结果集的语句，或者工具模式连接到某个segment或master上直接运行的sql语句，不会有segment把结果集发送给master的动作，便不会有gather motion动作。